chore: For WASI builds only, use fatalError in all .wait() calls. Recommend using .get() instead. #3421
Conversation
|
@MaxDesiatov @kateinoigakukun Would love to have your thoughts on this. Open to other solutions. But from what I've experienced so far, having this change could be very helpful for developers newly adopting swift nio into their WASI builds. |
scottmarchant
changed the title
scottmarchant
changed the title
scottmarchant
changed the title
scottmarchant
force-pushed
the
chore/improveErrorMessagingForWASIUsageOfNIO
branch
from
47b563d to
af8a704
Compare
|
Rebased these changes on the latest |
|
Arg, sorry: it looks like I lost track of that. Can you rebase again? |
scottmarchant
force-pushed
the
chore/improveErrorMessagingForWASIUsageOfNIO
branch
from
af8a704 to
8628263
Compare
@Lukasa This is rebased on the latest main now. |
| ) | ||
| #endif // os(WASI) | ||
|
|
||
| try self._blockingWaitForFutureCompletion(file: file, line: line) |
There was a problem hiding this comment.
This should fix CI breakage.
| try self._blockingWaitForFutureCompletion(file: file, line: line) | |
| return try self._blockingWaitForFutureCompletion(file: file, line: line) |
There was a problem hiding this comment.
Hmm, odd that those errors don't show up for me. But could be a linux vs macOS, or swift version difference thing.
https://github.com/apple/swift-nio/actions/runs/18985478598/job/54366370185?pr=3421
But I am seeing some compiler warnings in the wasm build. I don't think adding the return will address that warning. I'll push a slightly different revision that should resolve the warnings as well.
There was a problem hiding this comment.
Are the errors not reproducible with the exact same invocation and container image that CI uses?
docker run -v /home/runner/work/swift-nio/swift-nio:/swift-nio -w /swift-nio \
-e CI=true -e GITHUB_ACTIONS=true -e SWIFT_VERSION=6.0 \
-e workspace=/swift-nio swift:6.0-jammy bash
There was a problem hiding this comment.
@MaxDesiatov I didn't see that command during my cursory glance through the build logs because it was folded inline. I opted to just build this on my own fork instead to get as close as possible to the CI in this fork.
Here is the passing build testing my latest push to verify proper a proper build failure fix: https://github.com/PassiveLogic/swift-nio/actions/runs/19044020204/job/54387663452?pr=1
But to answer your question, that command does run on my machine, but it doesn't seem to kick off any swift builds.
I found the following similar command in the build log, but it fails for me at the apt-get step.
docker run -v /home/runner/work/swift-nio/swift-nio:/swift-nio -w /swift-nio -e CI=true -e GITHUB_ACTIONS=true -e SWIFT_VERSION=6.0 -e workspace=/swift-nio swift:6.0-jammy bash -c swift --version && apt-get update -y -q && apt-get install -y -q curl jq && curl -s --retry 3 https://raw.githubusercontent.com/apple/swift-nio/main/scripts/check-cxx-interop-compatibility.sh | bash
…existing blocking call in wait() will cause wasm executables to trap with an ambiguous message. This improves the message to help developers understand and correct the issue.
scottmarchant
force-pushed
the
chore/improveErrorMessagingForWASIUsageOfNIO
branch
from
8628263 to
22ae45a
Compare
scottmarchant
deleted the
chore/improveErrorMessagingForWASIUsageOfNIO
branch
4 participants
Use fatalError in all .wait() calls for WASI builds only, and point developers towards .get() instead.
Motivation:
While working to adopt NIO in some wasm code, I've commonly ran into issues any time code calls
.wait()during wasm runtime. Typically the executable either traps or crashes any time.wait()is called with an ambiguous error:Uncaught (in promise) RuntimeError: Atomics.wait cannot be called in this context. The error occurs because it is forbidden to block the main thread for a wasm executable, and the current implementation of.wait()blocks the calling thread.The fix is straight forward, all calls to
.wait()need refactor to.get(), which sometimes involves some Swift Concurrency adoption (eg.async) in the process. That change avoids blocking the main thread.Modifications:
Added
fatalErrorwith a descriptive error message to help developers identify the issue easier.Result:
For WASI builds only, changes the trap error message
Uncaught (in promise) RuntimeError: Atomics.wait cannot be called in this contextinto the following error message instead:Alternatives considered
.wait()completely out of nio for WASI builds, to turn runtime errors into compiler errors. That makes detection of this issue easier, but forces a refactor and breaking change, and somewhat precludes the possibility that WASI might support this down the road with a future change.Context
This PR is part of a larger effort by PassiveLogic to move Swift for WebAssembly support forward in a large number of dependencies.